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Abstract 
The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a 
protocol for tunneling a variety of data link protocols over IP 
networks. This document describes the specifics of how to tunnel 


Frame Relay over L2TPv3, including frame encapsulation, virtual- 
circuit creation and deletion, and status change notification. 


Townsley, et al. Standards Track [Page 1] 


RFC 4591 Frame Relay over L2TPv3 July 2006 


Table of Contents 


es STNEROJUCELOT wać A PPE ES 2 
kd. ¿ADDreviatioas susp the it oSA UKE WONG 4 PRA 3 
1..2:.. Specification of REQUITSMEDES mit W EO A KRA OE 3 

Zi GONGEol Connecti On EstabLiShMEŃG wiwa AW Silo RO ET AOKI 3 

3. PVC Status Notification and Session Establishment ............... 3 
Sula ALTEVI. Session -Bstablishment. seemed ekea is 4 
3r 2a, UŻITPYJ SESSTOŃR"FEAFdÓWN" ii ta O A Ed o ŁR 5 
Jada L2TPV3 SESSION: Maintenance as 5 
3.4. Use of the Circuit Status AVP for Frame Relay .............. 6 
3.5;. Frame Relay Header Length AVP wee sale tee ties pi be PY S F 

Aig Encapsulation sost zinc wait Za woz E el ale AA ena ded Sl E anes 7 
4 as Data Packet: Encapsulation inmi Wawa on gag ae ates 7 
4.2. Data. Packet “Sequencing -srisoberest aws ias Ea i ka SSE Ae SWE 9 
Ad MTU CONSTPOST ATION S s wałka kak aiw Wie ROC + RR Sue eaten see eats 9 

54, Applicability Statement: s «waw td doti SAWA i ais aja M ns aia ear ais 10 

6... Security: Considerations w aa sta i O a a aed: wh 10 

73 TAN Considerations id ia ed Kodiak waw ada le i en PS ES awa EL 
Palo [PSecudowLEe; Types ar a CE e, aos 11 
Tene RESULE- Code AVP Valles! a a as ARGE 
7.3. Control Message Attribute Value Pairs (AVPS) .............. 11 

8 AGKROWIEJGEMENCS: met arka iR ole Sepa eed aia! R GG O oska SRLS Sule 11 

O, References awa iR AAA WHS WZ AW PY ki ALA Pia WW ih 12 
Oe. Normative References tat PO a zo WE A R PAW 12 
0.2... -„ INFOTMACLVE Referentes 85 why AS A A WYRA 12 


1. Introduction 


[RFC3931] defines a base protocol for Layer 2 Tunneling over IP 
networks. This document defines the specifics necessary for 
tunneling Frame Relay over L2TPv3. Such emulated circuits are 
referred to as Frame Relay Pseudowires (FRPWs). 


Protocol specifics defined in this document for L2TPv3 FRPWs 
operating in a "virtual circuit-to-virtual circuit" mode include 
those necessary for frame encapsulation, PVC creation and deletion, 
and status change notification. Frame Relay traffic may also be 
transported in a "port-to-port" or "interface-to-interface" fashion 
using High-Level Data Link Control (HDLC) Pseudowires as defined in 
[RFC4349]. Support for Switched Virtual Circuits (SVCs) and 
Switched/Soft Permanent Virtual Circuits (SPVCs) are outside the 
scope of this document. 


The reader is expected to be very familiar with the terminology and 
protocol constructs defined in [RFC3931]. 
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1.1. Abbreviations 


FR Frame Relay 

FRPW Frame Relay Pseudowire 

LCCE L2TP Control Connection Endpoint (See [RFC3931]) 
PVC Permanent virtual circuit 

PW Pseudowire 

VC Virtual circuit 


1.2. Specification of Requirements 


In this document, several words are used to signify the requirements 
of the specification. These words are often capitalized. The key 
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 
are to be interpreted as described in [RFC2119]. 


2. Control Connection Establishment 


In order to tunnel a Frame Relay circuit over IP using L2TPv3, an 
L2TPv3 Control Connection MUST first be established as described in 
[RFC3931]. The L2TPv3 SCCRQ Control Message and corresponding SCCRP 
Control Message MUST include the Frame Relay Data Link Connection 
Identifier (DLCI) PW Type of 0x0001 (see IANA Considerations), in the 
Pseudowire Capabilities List, as defined in Section 5.4.3 of 
[RFC3931]. This identifies the control connection as able to 
establish L2TP sessions to support Frame Relay Pseudowires (FRPWs). 


An LCCE MUST be able to identify itself uniquely in the SCCRO and 
SCCRP messages via a globally unique value. By default, this is 
advertised via the structured Router ID Attribute Value Pairs (AVP) 
[RFC3931], though the unstructured Hostname AVP [RFC3931] MAY be used 
to identify LCCEs as well. 


3. PVC Status Notification and Session Establishment 


This section specifies how the status of a PVC is reported between 
two LCCEs. This includes what should happen when a PVC is created, 
deleted or when it changes state between ACTIVE and INACTIVE. When 
emulating a Frame Relay service, if the procedures for PVC status 
management defined in [0933] Annex A are being used between an LCCE 
and the attached Remote System, an LCCE MUST participate in them (see 
Section 3.3). 
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3.1. L2TPv3 Session Establishment 


PVC creation (provisioning) results in establishment of an L2TP 
session via the standard three-way handshake described in Section 
3.4.1 of [RFC3931]. An LCCE MAY initiate the session immediately 
upon PVC creation or wait until the PVC state transitions to ACTIVE 
before attempting to establish a session for the PVC. Waiting until 
the PVC transitions to ACTIVE may be preferred, as it delays 
allocation of L2TP resources until it is absolutely necessary. 


The Pseudowire Type AVP defined in Section 5.4.4 of [RFC3931], 
Attribute Type 68, MUST be present in the Incoming-Call-Request 
(ICRQ) messages and MUST include the Frame Relay DLCI PW Type of 
0x0001 for FRPWs. 


The Circuit Status AVP (see Section 3.4) MUST be present in the ICRO 
and Incoming-Call-Reply (ICRP) messages and MAY be present in the Set 
Link Info (SLI) message for FRPWs. 


The Frame Relay Header Length AVP (see Section 3.5) MAY be present in 
the ICRQ and ICRP messages. 


The following is an example of the L2TP messages exchanged for an 
FRPW that is initiated after a new PVC is provisioned and becomes 
ACTIVE. 


LCCE (LAC) A LCCE (LAC) B 


FR PVC Provisioned 
FR PVC Provisioned 
FR PVC ACTIVE 
ICRQ (status = 0x03) ----> 
FR PVC ACTIVE 
<---- ICRP (status = 0x03) 
L2TP session established, 
OK to send data into tunnel 
L2TP session established, 
OK to send data into tunnel 
In the example above, an ICRQ is sent after the PVC is created and 


becomes ACTIVE. The Circuit Status AVP indicates that this PVC is 
ACTIVE and New (0x03). The Remote End ID AVP [RFC3931] MUST be 
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present in the ICRQ in order to identify the PVC (together with the 
identity of the LCCE itself, as defined in Section 2) to associate 
the L2TP session with. The Remote End ID AVP, defined in [RFC3931], 
is of opaque form and variable length, though one MUST at a minimum 
support use of an unstructured four-octet value that is known to both 
LCCEs (either by direct configuration, or some other means). The 
exact method of how this value is configured, retrieved, discovered, 
or otherwise determined at each LCCE is outside the scope of this 
document. 


As with the ICRQ, the ICRP is sent only after the FR PVC transitions 
to ACTIVE as well. If LCCE B had not been provisioned for the PVC 
identified in the ICRQ, a Call-Disconnect-Notify (CDN) would have 
been immediately returned indicating that the circuit was not 
provisioned or available at this LCCE. LCCE A SHOULD then exhibit a 
periodic retry mechanism. If so, the period and maximum number of 
retries MUST be configurable. 


An Implementation MAY send an ICRQ or ICRP before a PVC is ACTIVE, as 
long as the Circuit Status AVP reflects that the PVC is INACTIVE and 
an SLI is sent when the PVC becomes ACTIVE (see Section 3.3). 


The Incoming-Call-Connected (ICCN) is the final stage in the session 
establishment, confirming the receipt of the ICRP with acceptable 
parameters to allow bidirectional traffic. 


3.2. L2TPv3 Session Teardown 


In the event that a PVC is deleted (unprovisioned) at either LCCE, 
the associated L2TP session MUST be torn down via the CDN message 
defined in Section 3.4.3 of [RFC3931]. 


General Result Codes regarding L2TP session establishment are defined 
in [RFC3931]. Additional Frame Relay result codes are defined as 
follows: 


17: FR PVC was deleted permanently (no longer provisioned) 18: FR 
PVC has been INACTIVE for an extended period of time 19: 
Mismatched FR Header Length 


3.3. L2TPv3 Session Maintenance 


FRPW over L2TP makes use of the SLI control message defined in 
[RFC3931] to signal Frame Relay link status notifications between 
LCCEs. This includes ACTIVE or INACTIVE notifications of the VC, and 
any other parameters that may need to be shared between the tunnel 
endpoints or LCCEs in order to provide proper PW emulation. The SLI 
message is a single message that is sent over the L2TP control 
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channel signalling the state change. Since the message is delivered 
reliably, there is no additional response or action required of the 
PW subsystem to ensure that the state change notification was 
received by the tunnel peer. 


The SLI message MUST be sent any time there is a circuit status 
change that may be reported by any values identified in the Circuit 
Status AVP. The only exceptions to this are the initial ICRQ, ICRP, 
and CDN messages, which establish and tear down the L2TP session 
itself when the PVC is created or deleted. The SLI message may be 
sent from either LCCE at any time after the first ICRQ is sent (and 
perhaps before an ICRP is received, requiring that the peer to 
perform a reverse Session ID lookup). 


An LCCE participating in the procedures for PVC status management 
defined in [0933], Annex A, MUST transmit an SLI message including 
the Circuit Status AVP (see Section 3.4) when it detects a change in 
the status for a particular local FR PVC (i.e., when it detects a 
service-affecting condition or the clearing of such a condition). An 
LCCE receiving an SLI message indicating a change in the status of a 
particular FRPW SHOULD generate corresponding updates for the FR PVC 
towards the Remote System, as defined in [0933], Annex A. 


All sessions established by a given control connection utilize the 
L2TP Hello facility, defined in Section 4.4 of [RFC3931], for session 
keepalive. This gives all sessions basic dead peer and path 
detection between LCCEs. 


3.4. Use of the Circuit Status AVP for Frame Relay 


Frame Relay circuit status is reported via the Circuit Status AVP 
defined in [RFC3931], Attribute Type 71. For reference, this AVP is 
shown below: 


0 1 

Oi 2: 8 405.005 Ay Bu Oe O" A 32: 3-44: 5 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Reserved |N|A| 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


The Value is a 16-bit mask with the two least significant bits 
defined and the remaining bits reserved for future use. Reserved 


bits MUST be set to 0 by the sender and ignored by the receiver. 


The N (New) bit indicates whether the Circuit Status indication is 
for a new FR PVC (1) or an existing FR PVC (0). 
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3. 


4. 


The A (Active) bit indicates whether the FR PVC is ACTIVE (1) or 
INACTIVE (0). 


5. Frame Relay Header Length AVP 


The "Frame Relay Header Length AVP", Attribute type 85, indicates the 
number of bytes in the Frame Relay header. The two peer LCCEs MUST 
agree on the length of the Frame Relay header. 


This AVP is exchanged during session negotiation (in ICRQ, ICRP). If 
the other LCCE supports a different Frame Relay header length, the 
associated L2TP session MUST be torn down via CDN message with result 
code 19 (see Section 3.2). 


If the Frame Relay Header Length AVP is not signalled, it MUST be 
assumed that the peer uses a 2-byte Frame Relay header. 


The Attribute Value field for this AVP has the following format: 
Frame Relay Header Length (ICRQ, ICRP) 
0 1 
0123456 789012345 
++-+-+-+-+-+-+-+-4+-+-+-+-+-+-+-+ 
| Frame Relay Header Length | 
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


The Frame Relay Header Length Type is a 2-octet unsigned integer with 
the following values defined in this document: 


2: Two-octet Frame Relay Header 4: Four-octet Frame Relay Header 
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 
AVP MAY be set to 0 but MAY vary (see Section 5.2 of [RFC3931]). The 
length (before hiding) of this AVP is 8. 


Encapsulation 


.1. Data Packet Encapsulation 


The FR PDU is transported in its entirety, excluding the opening and 
closing High Level Data Link Control (HDLC) flags and the frame check 
sequence (FCS). Bit stuffing is undone. The L2TPv3 Session Header 
is that as defined in [RFC3931]. If sequencing or other features 
require presence of an L2-Specific Sublayer, the Default format 
defined in Section 4.6 of [RFC3931] MUST be used. 
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The FR header is defined in [0922]; however, the notation used 
differs from that used in IETF specifications. For reference, the FR 
header (referred to as Address Field in [0922]) in IETF notation is 

0 1 


0123456789012345 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| hi dlci |C|O|lo dlci|F|B|p|1| 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Two-octet FR Header 


0 1 2 3 
0OL12Z234567%78950133465 6786901234 5-.6708 90.1 
++-+-+-+-+-+-+-+ + ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| hi alci |clO| dlci |F|B|p|O|  dlci [0| dlci_lo |o|1| 
++4-+-+-+-+-+-+-+ + ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Four-octet FR Header 
C/R (bit 6) FR frame C/R (command/response) bit [0922]. 


F - FECN (bit 12): FR FECN (Forward Explicit Congestion 
Notification) bit [0922]. 


B - BECN (bit 13): 

FR BECN (Backward Explicit Congestion Notification) bit [0922]. 

D - DE (bit 14) FR DE bit indicates the discard eligibility [0922]. 
Usage of the C/R, FECN, BECN, and DE bits is as specified in [0922]. 


The C/R bit is conveyed transparently. Its value MUST NOT be changed 
by the LCCE. 


The FECN bit MAY be set by the LCCE to notify the receiving end-user 
that the frames it receives have encountered congestion. The end- 
user may use this indication for destination-controlled transmit rate 
adjustment. The bit must never be cleared by the LCCE. If the LCCE 
does not support FECN, it shall pass the bit unchanged. 


The BECN bit MAY be set by the LCCE to notify the receiving end-user 
that the frames it transmits may encounter congestion. The end-user 
may use this indication to adjust its transmit rate. The bit must 
never be cleared by the LCCE. If the LCCE does not support BECN, it 
shall pass the bit unchanged. 
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The DE bit MAY be set by a policing function on the LCCE to indicate 
that this frame SHOULD be discarded in preference to other frames in 
a congestion situation. The bit must never be cleared by the LCCE. 
If the LCCE does not support DE, it shall pass the bit unchanged. 


The encapsulation of Frame Relay frames with the two-octet FR Header 
is REQUIRED. The encapsulation of Frame Relay frames with the four- 
octet FR Header is OPTIONAL. The encapsulation of Frame Relay frames 
with the three-octet FR Header is outside the scope of this document. 


4.2. Data Packet Sequencing 


Data Packet Sequencing MAY be enabled for FRPWs. The sequencing 
mechanisms described in [RFC3931] MUST be used for signalling 
sequencing support. FRPW over L2TP MUST request the presence of the 
L2TPv3 Default L2-Specific Sublayer when sequencing is enabled and 
MAY request its presence at all times. 


If the FRPW is known to be carrying data that does not require packet 
order be strictly maintained (such as IP), then packet sequencing for 
the FRPW SHOULD NOT be enabled. 


4.3. MTU Considerations 
With L2TPv3 as the tunneling protocol, the packet resulted from the 
encapsulation is N bytes longer than Frame Relay frame without the 
opening and closing HDLC flags or ECS. The value of N depends on the 
following fields: 


L2TP Session Header: 


Flags, Ver, Res 4 octets (L2TPv3 over UDP only) 
Session ID 4 octets 
Cookie Size 0, 4, or 8 octets 


L2-Specific Sublayer 0 or 4 octets (i.e., with sequencing) 


Thus, the range for N in octets is: 


N 4 - 16 L2TPv3 data messages are over IP 
N 16 - 28 L2TPv3 data messages are over UDP 
(N does not include the IP header) 


The MIU and fragmentation implications resulting from this are 
discussed in Section 4.1.4 of [RFC3931]. 
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Applicability Statement 


The Frame Relay PW emulation described in this document allows a 
service provider to offer a Frame Relay PVC-based service across an 
IP packet-switched network (PSN). A Frame Relay port-based service 
can be offered using [RFC4349]. 


The FRPW emulation has the following characteristics in relationship 
to the native service: 


o There is a one-to-one mapping between a Frame Relay PVC and an 
FRPW, supporting bi-directional transport of variable length 
frames. The Frame Relay frame is transported in its entirety, 
including the DLCI and the C/R, FECN, BECN, and DE bits, but 
excluding the opening and closing flags and the FCS. The egress 
LCCE re-writes the DLCI and regenerates the FCS. 


o Two- and four-octet address fields are supported. The length is 
negotiated between LCCEs during session establishment (see Section 
369) 


o The availability or unavailability of the PVC is signalled between 
LCCEs using the Circuit Status AVP (see Section 3.4). Loss of 
connectivity between LCCEs can be detected by the L2TPv3 keepalive 
mechanism (see Section 4.4 in [RFC3931]). These indications can be 
used to determine the PVC status to be signalled through [0933] 
procedures at the Frame Relay interface. 


o The maximum frame size that can be supported is limited by the PSN 
MTU, unless fragmentation and reassembly is used (see Section 4.1.4 
of [RFC3931]). 


o Sequencing may be enabled on the FRPW to ensure that frames are 
delivered in order (see Section 4.2). 


o Quality of Service characteristics, such as throughput (CIR), 
committed burst size (bc), excess burst size (be), and priority, 
can be provided by leveraging Quality of Service features of the 
LCCEs and the underlying PSN. 


Security Considerations 


Frame Relay over L2TPv3 is subject to the security considerations 
defined in [RFC3931]. There are no additional considerations 
specific to carrying Frame Relay that are not present for carrying 
other data link types. 
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7. IANA Considerations 
7.1. Pseudowire Type 


The following value for the Frame Relay DLCI PW Type (see Pseudowire 
Capabilities List, as defined in 5.4.3 of [RFC3931], and L2TPv3 
Pseudowire Types in 10.6 of [RFC3931]) is allocated by the IANA 
(number space already created as part of publication of [RFC3931]): 


L2TPv3 Pseudowire Types 


0x0001: Frame Relay DLCI Pseudowire Type 
7.2. Result Code AVP Values 


This number space is managed by IANA as described in Section 2.3 of 
[RFC3438]. Three new L2TP Result Codes for the CDN message appear in 
Section 3.2. The following is a summary: 


Result Code AVP (Attribute Type 1) Values 


17: PVC was deleted permanently (no longer provisioned) 
18: PVC has been INACTIVE for an extended period of time 
19: Mismatched FR Header Length 


7.3. Control Message Attribute Value Pairs (AVPs) 
This number space is managed by IANA as described in Section 2.2 of 
[RFC3438]. An additional AVP Attribute, specified in Section 3.5, 


was allocated for this specification: 


Control Message Attribute Value Pairs 


85: Frame Relay Header Length 
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